เรื่อง Devๆ ที่ UX Designer ควรรู้ #2: UI Components และ Frameworks
จากบทความตอนที่แล้ว (เรื่อง Devๆ ที่ UX Designer ควรรู้ #1: เข้าใจการโค้ด UI เพื่อออกแบบให้เป๊ะยิ่งขึ้น) เราได้คุยเรื่องพื้นฐานความเข้าใจในการโค้ด UI ของ Developer กันไปแล้ว วันนี้จะมาเล่าต่อตามที่สัญญาไว้ครับ 😊
ใครที่ได้อ่านตอนที่แล้ว คงจะได้เห็นแล้วว่าโค้ดสำหรับ UI ทำงานอย่างไร มีการวาดกล่องลงบนจอจากบนลงล่างและตกแต่งด้วย CSS ฯลฯ ในบทความนี้เราจะมาต่อกันเรื่องหลักการเกี่ยวกับ UI Components และ Framework ต่างๆ ทั้งนี้อย่าเพิ่งตกใจไป ถ้าคำเหล่านี้ไม่คุ้นหู ก่อนจะไปถึงตรงนั้น เราจะมาเริ่มจากแนวคิดพื้นฐานของ Developer ในการทำซอฟต์แวร์กันก่อน…
“Don’t Repeat Yourself”
ปกติเวลาเขียนซอฟต์แวร์ จะมีหลักการใหญ่ๆ อยู่อันนึงที่เรียกว่า “DRY” ย่อมาจาก “Don’t Repeat Yourself” ความหมายก็คือ เวลาเขียนโปรแกรม อย่าเขียนอะไรซ้ำสองรอบ อะไรที่ใช้ซ้ำได้ก็ให้นำมาใช้ซ้ำ อย่างเช่น ถ้าเขียนโค้ดสร้างปุ่มไปแล้วครั้งนึง ก็อย่าให้ต้องเขียนซ้ำอีกครั้งในส่วนอื่นๆ ของโค้ด
สาเหตุที่มีหลักการนี้ขึ้นมา เพราะถ้าเราเขียนโค้ดที่ทำสิ่งเดียวกันไว้ในหลายๆ ที่ พอต้องแก้ขึ้นมาก็จะวุ่นวายใหญ่ ต้องตามไปแก้ทุกที่ ยิ่งเพิ่มโค้ดก็ยิ่งเพิ่มบั๊ก ดังนั้นอะไรใช้ซ้ำได้ก็ใช้ซ้ำจะดีกว่า
ในมุม Designer ให้ลองสมมติถึงเวลาที่เราทำจอไว้ใน Figma ทั้งหมด 30 จอแล้วอยากเปลี่ยนสีปุ่ม ก็ต้องตามไปแก้ให้หมด แก้ครบบ้าง หลุดบ้าง จนทำให้เกิดฟีเจอร์ที่ช่วยแก้ปัญหานี้ คือ “Components” นั่นเองครับ ซึ่งระบบ Components ทำงานคล้ายกับการจัดการโค้ด UI Components ของ Developer ดังนั้นหากเราใช้ Components ใน Figma อย่างเป็นระบบ หรือทำได้ถึงขั้นสร้าง Design System ก็จะช่วยให้ Developer เข้าใจ Design ของเราได้ง่ายขึ้น
UI Components ในโค้ด หน้าตาเป็นอย่างไร?
เมื่อเข้าใจหลักการ DRY แล้ว เรามาลองดูกันว่า UI Components ในโค้ดทำงานอย่างไร เพื่อให้เราสร้าง Components ได้ใกล้เคียงกับการโค้ดมากขึ้นครับ
ของใช้ซ้ำบ่อยๆ ก็สร้างเป็น Component ให้ใช้ซ้ำง่ายๆ
สมมติว่าเรามีปุ่มแบบพิเศษแบบนึงที่ใช้บ่อยๆ ถ้าเราเขียนโค้ดวาดปุ่มใหม่ทุกครั้ง ก็จะเป็นการซ้ำซ้อน ดังนั้นเราจะแยกโค้ดส่วนที่วาดปุ่มพิเศษนี้ออกมาเป็น Component โดยอาจจะตั้งชื่อใหม่ว่า <MyButton> เมื่อใดที่อยากจะใช้ ก็แค่เขียนโปรแกรมสั้นๆ ว่า “จงวาดปุ่มแบบ <MyButton>”
ตั้งค่า Component ด้วย Properties
ทีนี้เวลาเอาไปใช้จริง เราอาจจะอยากให้มันปรับได้อีกหลายๆ แบบ เช่น เปลี่ยนสี ทำเป็นปุ่มแบบ Outline เพิ่มไอคอนบนปุ่ม ฯลฯ ซึ่งการแยกออกมาเป็น <MyButton> เฉยๆ อาจไม่เพียงพอ เพราะถ้าแค่แยกโค้ดออกมาเฉยๆ ก็อาจจะต้องทำปุ่มหลายเวอร์ชันอยู่ดี เช่น <PrimaryButton> <SecondaryButton>
สำหรับ Developer ในกรณีแบบนี้ แทนที่จะต้องทำปุ่มแยกหลายๆ แบบ เวลาเขียนโค้ด UI จริงๆ ก็จะกำหนดลักษณะเหล่านี้เป็น “Properties” ของปุ่มให้เปลี่ยนค่าได้ เหมือนเป็นการเพิ่ม “โหมด” ให้กับ Component นั้น เช่น <MyButton> อาจจะมี Properties ต่างๆ เช่น
- ประเภท: Primary, Secondary (Outline), Link
- สี: ระบุโค้ดสีอะไรก็ได้
- ไอคอน: ไม่มีไอคอน, มีไอคอน (ถ้ามีก็ระบุไอคอนว่าใช้ไอคอนไหน)
- ขนาด: Small, Medium, Large
- State: Default, Hover, Pressed, Disabled
เวลาเขียนโค้ดจะออกมาเป็นประมาณนี้ คือใช้ <MyButton> เหมือนเดิม แต่ระบุลักษณะเพิ่มเติมเข้าไป
<MyButton type="primary" icon="add" size="medium" color="#2BD4AB">
Button
</MyButton>ใครที่ใช้ Figma คล่องๆ มาถึงจุดนี้ก็คงเริ่มรู้สึกว่ามันเหมือนระบบ Variants และ Component Properties แบบในภาพนี้นั่นเอง
ดังนั้นทางหนึ่งที่จะช่วยให้ Developer ทำงานได้ง่ายขึ้นคือการใช้ Components, Variants, และ Property ให้คล่อง เพราะจะช่วยให้ Developer ออกแบบ Component ในโค้ดให้มีตัวเลือกที่ตรงกับความตั้งใจของเรามากขึ้น แต่สำหรับใครที่ยังไม่คุ้นหรือไม่คล่องเรื่องนี้ ก็ลองศึกษาเพิ่มเกี่ยวกับ Components, Variants และ Properties ได้ครับ
มีค่าสี ค่าตัวเลขที่ใช้บ่อยๆ? ลองใช้ Design Tokens เลย
เมื่อมีการเปลี่ยนสี เปลี่ยนไอคอนแล้ว หลายครั้งในงานออกแบบของเราก็มักจะมีค่าตัวเลข ฟอนต์ หรือค่าสีที่ใช้บ่อยๆ และต้องการทำให้เป็นระบบเพื่อไม่ให้เกิดปัญหาว่าใช้โค้ดสีไม่เท่ากัน หรือใช้ขนาดฟอนต์สะเปะสะปะ ทาง Developer ก็จะมีการแก้ปัญหานี้โดยการตั้งชื่อเฉพาะให้ค่าแต่ละค่าเป็น “ตัวแปร” เช่น เรียกชื่อสี #14e1ca ว่า “primary” หรือเรียกมุมมนขนาด 8px ว่า “corner-default” เป็นต้น
สำหรับฝั่ง Designer วิธีคิดแบบนี้กำลังเป็นที่สนใจในวงการในชื่อ “Design Tokens” ครับ ซึ่งการทำแบบนี้จะเหมือนกับหลักพื้นฐานของ Design Token คือเป็นการตั้งชื่อมาตรฐานให้กับค่าที่ใช้บ่อยๆ ตั้งแต่สี ฟอนต์ ระยะห่าง รัศมีความมน ขนาดไอคอน ฯลฯ (ลองอ่านเรื่อง Design Tokens เพิ่มเติมได้ที่นี่)
สำหรับเครื่องมืออย่าง Figma เราสามารถเก็บค่าสีและฟอนต์เป็น “Styles” ได้ โดยการใช้ฟีเจอร์พวกนี้ใน Design ของเราจะช่วยให้ Developer สามารถสร้างชุดตัวแปรไว้ใช้งานตามที่เราออกแบบได้
ทั้งนี้ Figma ในตอนนี้ (ธันวาคม 2022) จะยังทำ Design Token ได้ไม่สมบูรณ์นัก ทำได้แค่เรื่องสี ฟอนต์ และ Effect อื่นๆ อีกเล็กน้อย ถ้าอยากทำได้มากกว่านี้อาจจะต้องใช้ Plug-In เพิ่มเติม ในเมื่อ Figma ยังทำไม่ได้ สิ่งที่ควรทำคือเมื่อส่ง Design ให้ Developer ก็ควรจะระบุค่าที่ใช้บ่อยๆ เหล่านี้ใน Design System ของเราด้วยนั่นเองครับ
ใครที่อ่านตั้งแต่บทความที่แล้วมาจนถึงตรงนี้ คงจะพอนึกภาพออกมากขึ้นแล้วว่าการเขียนโค้ด UI เป็นอย่างไร การนำ Component มาใช้ซ้ำเป็นอย่างไร แต่ถึงจุดนี้ ผมอยากจะเล่าส่วนสำคัญอีกอย่างที่ Designer ควรรู้ไว้…
ความจริงแล้ว Developer ไม่ได้โค้ด UI ใหม่ตั้งแต่ต้นทุกครั้ง
จากที่เล่าไปว่า Developer ยึดหลัก DRY ที่จะไม่เขียนโค้ดซ้ำถ้าไม่จำเป็น แม้ส่วนใหญ่จะใช้หลักการนี้กับโค้ดของตัวเอง แต่ถ้ามองภาพกว้างๆ เราก็ไม่จำเป็นต้องเขียนโค้ดซ้ำกับที่คนอื่นเขียนไปแล้วด้วยเช่นกัน!
ยกตัวอย่างเช่น การสร้างปุ่มหรือการจัด Layout พื้นฐานของตัวแอป ที่ไม่ว่าจะเป็น Developer คนไหนมาเขียนโค้ด ก็จะต้องทำอะไรแบบเดียวกันซ้ำๆ อยู่เสมอ ดังนั้นเมื่อมีอะไรที่ Developer ทำซ้ำกันบ่อยๆ ก็มักจะมีคนเขียนโค้ด Component พวกนี้รวมไว้เป็น “Library” ออกมาแจกจ่ายให้คนอื่นสามารถนำไปใช้ซ้ำได้โดยไม่ต้องเขียนเองแต่ต้น ช่วยประหยัดเวลาเขียนโค้ดได้อย่างมาก
ในมุม Designer ก็ควรจะทำความรู้จักกับ UI Components ไว้ในหลายๆ ระดับ ตั้งแต่ว่าตัว OS/Browser มี Components แบบไหนให้ใช้บ้าง
Native UI Components
Native Components คือชิ้นส่วน UI แบบ Default ที่ติดมากับระบบ OS ของเครื่องหรือ Web Browser ซึ่ง OS หรือ Browser แต่ละตัวจะมี Component ให้ใช้งานหลากหลายต่างๆ กันไป ทั้งที่เล็กๆ อย่างระดับปุ่ม กล่องข้อความ หรือใหญ่ๆ ที่อาจจะเป็นโครงสร้างของทั้งแอปเลยอย่าง Layout หรือ Grid หรือแถบเมนูด้านล่างที่มีในแทบทุกแอปก็มีให้ใช้เป็น Native Component เช่นกัน
ทั้งนี้ Component ของแต่ละแพลตฟอร์มอาจจะมีหน้าตาและการใช้งานแตกต่างกันไป เช่น กล่องข้อความพื้นฐานใน Windows/Mac หรือ iOS/Android หรือ Chrome/Firefox/Safari จะมีหน้าตาไม่เหมือนกัน หรือแม้กระทั่งชิ้น UI เดียวกันใน Chrome บนคอมกับบนมือถือ ก็ยังทำงานไม่เหมือนกัน ยกตัวอย่างของที่ใช้บ่อยๆ เช่น Select Box หรือ Date Picker ในภาพตัวอย่างด้านล่าง
สำหรับการทำความเข้าใจ Native Components สิ่งที่ Designer ควรรู้มีดังนี้
- OS/Browser ที่แอปของเราจะไปลง มี Components อะไรให้ใช้บ้าง โดยลองศึกษา Design Guide ของแต่ละแพลตฟอร์ม เช่น HTML UI Elements (Web), Material Design (Android), Apple Human Interface Guidelines (iOS/macOS), Fluent UI (Windows)
- ดูว่าการใช้งาน Components แต่ละแบบเป็นอย่างไร เหมาะกับการใช้งานที่เราต้องการไหม
- Components ที่ระบบมีให้ สามารถปรับแต่งอะไรได้บ้าง เช่น กล่องข้อความใน Web Browser สามารถปรับขนาด สี ฟอนต์ กรอบข้อความ ฯลฯ ได้
- แต่ละ Component มี State อะไรบ้าง เพื่อเวลาเราออกแบบ UI เวอร์ชันของเราเองที่ดัดแปลงจาก Native Component จะได้เก็บเคสต่างๆ ครบถ้วน เช่นกล่องข้อความบนเว็บมี State คือ Empty, Filled, Focused, Hover, Disabled, Error, etc.
การที่เราเข้าใจ Native Components แบบนี้ จะช่วยทุ่นแรงในการออกแบบ Interaction ได้ระดับหนึ่ง เพราะไม่ใช่ว่า UI Designer จะต้องสร้าง Component ใหม่ทุกครั้งกับทุกแอป แต่เราสามารถหยิบชิ้นส่วนต่างๆ ที่ระบบมีให้อยู่แล้วมาใช้งานได้ ช่วยลดเวลาให้กับทั้ง Designer และ Developer ได้อย่างมาก
แต่ถ้าสังเกตในตัวอย่างด้านบน จะเห็นว่าบางแอปมีการใช้ UI Element แบบ Custom ทำเองขึ้นมา นำมาสู่คำถามต่อไปว่า…
เราควรใช้ UI Components แบบ Native หรือทำเองดี?
การใช้ UI Components ทั้งสองแบบมีข้อดีข้อเสียแตกต่างกัน ดังนี้
ข้อดีของการใช้ Native Component
- ประหยัดเวลา ในการออกแบบ Component แบบต่างๆ ไม่ต้องคิดใหม่ ไม่ต้องออกแบบใหม่ นำมาใช้ได้เลย เพราะ Native Component ส่วนใหญ่จะคิดมาให้ค่อนข้างครบแล้ว
- ประหยัดแรงของ Developer ในการเขียนโค้ดและดูแลโค้ดส่วนที่เพิ่มเข้ามา ไม่เสี่ยงกับบั๊กหรือปัญหาแปลกๆ ที่อาจเกิดขึ้นถ้าทำ Component เอง
- รองรับ State ต่างๆ ครบถ้วน รองรับการใช้งานทุกรูปแบบ เช่น Select Box ที่เลือกตัวเลือกได้ทั้งจากการคลิกเมาส์ ปุ่มลูกศรบนคีย์บอร์ด การพิมพ์ตัวอักษรเพื่อค้นหาตัวเลือก การแตะหน้าจอ ฯลฯ
- ได้ Accessibility ที่ดี เพราะพวกโปรแกรมอ่านหน้าจอถูกออกแบบมาให้อ่าน Native Components ได้ถูกต้องอยู่แล้ว ถ้าทำ Component เองมักมีการอ่านผิด เช่น ปุ่มทำเองอาจจะโดนอ่านว่าเป็นกล่อง Content ธรรมดา แทนที่จะเป็นปุ่ม ทำให้ผู้ใช้สับสน
- แอปทำงานได้เร็วกว่า เพราะ Native Components ถูกออกแบบมาให้ทำงานบนแพลตฟอร์มนั้นโดยตรง
- ปรับแต่งหน้าตาได้บ้าง เพื่อให้เข้ากับแบรนด์
ข้อดีของการใช้ Custom Component (ทำเอง)
- Customize หน้าตาและลักษณะการใช้งานได้มากกว่า ทำให้สามารถควบคุมภาพลักษณ์แบรนด์ของแอปได้เต็มที่
- เพิ่มฟีเจอร์ให้กับ Component นั้นๆ เช่น เพิ่มกล่อง Search ใน Select Box หรือแบ่งตัวเลือกใน Select Box เป็นกลุ่มๆ มีหัวข้อย่อยกำกับ
- ออกแบบ Component ใหม่เพื่อการใช้งานที่ดีกว่า เช่น ต้องการให้ผู้ใช้กดเลือกโค้ดสี แต่ Color Picker ที่ระบบมีให้ใช้ยากไป ไม่เหมาะกับกลุ่มผู้ใช้ของเรา
ดังนั้นในฐานะ Designer เราจะต้องตัดสินใจว่า UI Components แต่ละชิ้นที่เราใช้ จำเป็นจะต้องนำมาสร้างใหม่หรือไม่ หรือจะตกแต่งเพิ่มใหม่จาก Native Components เดิมที่ระบบมีอยู่
เพราะถ้าสร้าง Component ใหม่จากศูนย์ แม้จะได้ความยืดหยุ่นมากกว่า แต่ถ้าไม่ระวังให้ดี ก็มีโอกาสที่จะเสียหลายๆ ฟีเจอร์ไป และอาจทำให้ Component ของเราไม่รองรับการใช้งานบางแบบ สร้างปัญหาให้กับผู้ใช้แทน
UI/CSS Frameworks
นอกจาก Native Components แล้ว อีกสิ่งที่ควรรู้จักคือ UI Framework หรือถ้าเป็นคนทำเว็บอาจจะคุ้นเคยกับคำว่า CSS Framework นั่นเอง
UI Frameworks ในที่นี้ก็คือ Library แบบหนึ่ง ซึ่งมีคนสร้างมาเพื่อ “ครอบ” หรือใช้แทน Native Components เพื่อทำให้ได้ชุด UI ที่ดูสวยงามขึ้น หรือมีฟีเจอร์มากขึ้นนั่นเอง ซึ่ง UI Framework ส่วนใหญ่จะใช้กับงานทำเว็บ
ในวงการ Web Developer ทุกวันนี้มี UI Frameworks ที่นิยมใช้กันอยู่หลายชุด เช่น Bootstrap, MUI และ Tailwind CSS ซึ่ง Framework แต่ละชุดก็จะมี Component ต่างๆ ให้ใช้คล้ายๆ กัน เช่น มีปุ่มสวยๆ ให้ใช้ มีระบบ Grid ให้จัดหน้าง่ายๆ บางชุดมีไอคอนมาให้ด้วย เป็นต้น ถ้าเทียบกับ Native Component ของ Browser แล้ว การใช้ Frameworks พวกนี้ก็จะช่วยให้งานของเราหน้าตาดูดีขึ้น
ในการทำงานจริง เมื่อ Developer ได้รับ Design จากเราไป (โดยเฉพาะถ้าเป็นไฟล์ Design System) มักจะเริ่มจากการนำ CSS Framework ตัวหนึ่งมาตั้งต้น แล้วนำไปดัดแปลงให้หน้าตาเหมือนที่เราออกแบบไว้ ไม่จำเป็นต้องสร้าง Component ทุกชิ้นใหม่จากศูนย์เสมอ
ทั้งนี้ Framework แต่ละตัวมีความแตกต่างกันเล็กน้อยที่อาจจะกระทบกับการทำงานของ Designer เช่น ใช้จำนวน Column ในระบบ Grid ไม่เท่ากัน, กำหนดจุด Breakpoints ไม่เท่ากัน, Components ที่มีมาให้ต่างกัน, หรือความเคร่งในการใช้ Design Tokens เป็นต้น ซึ่งคงเป็นไม่ได้ที่ Designer ทุกคนจะรู้จักทุกรายละเอียดของทุก Framework และ Developer แต่ละทีมหรือแต่ละคนก็ถนัดใช้ Framework คนละตัวกัน ดังนั้นทางที่ดีที่สุดก็เช่นเดิมครับ คือเราควรทำงานกับ Developer อย่างใกล้ชิดและคุยกันอยู่เสมอว่าเขาทำอะไรให้เราได้หรือไม่ได้บ้าง
Grid System
ส่วนที่แล้วเราพูดถึง Grid System แบบผ่านๆ กันไปบ้าง แต่จริงๆ Grid System เป็นอีกสิ่งสำคัญที่มักจะมาพร้อมกับ UI Framework จึงอยากจะเล่ารายละเอียดแถมไว้ตรงนี้ด้วยครับ เพราะเป็นเรื่องสำคัญมากๆ ที่จะช่วยให้ Designer ออกแบบได้ดีขึ้น นำไปเขียนโค้ดได้ง่ายขึ้น
Grid System ที่ติดมาพร้อมกับ UI Framework คือระบบจัด Layout ของ UI ให้เป็นระเบียบ โดยจะมีส่วนประกอบหลักๆ คือ Container, Row และ Column
- Layout ของหน้า UI จะถูกจำกัดความกว้างด้วย Container
- ใน Container จะถูกแบ่งเป็นบรรทัดๆ (Row) จากบนลงล่าง
- ในแต่ละ Row จะถูกแบ่งเป็น Column เท่าๆ กันจากซ้ายไปขวา เว้นระยะห่าง (Gap) เท่าๆ กัน
- เวลาเราวางกล่องของ UI ลงไป สามารถวางพาดหลาย Column ได้
Framework ส่วนใหญ่จะรองรับจำนวน Column อยู่ที่ 12 Columns การวางกล่องต่างๆ ลงใน UI ก็จะระบุหน่วยความกว้างเป็น Column เช่น ให้กล่องนี้กว้าง 3 Columns เป็นต้น อย่างในรูปด้านล่างนี้
สำหรับจอขนาดอื่นๆ เรายังสามารถระบุได้ว่าที่แต่ละ Breakpoint (ที่เล่าไปในตอนที่แล้ว) เราต้องการให้แต่ละกล่องมีความกว้างคิดเป็นกี่ Column โดยที่เมื่อจอขนาดเล็กลง บางกล่องอาจจะถูกขยับลงมาเป็นบรรทัดใหม่แทน เช่น กล่องสีเขียวในภาพด้านล่าง เมื่อเป็นจอขนาดใหญ่จะมีความกว้าง 3 Columns แต่พอจอขนาดกลางจะเหลือ 6 Column และถ้าเล็กลงไปอีกก็กินเต็มความกว้าง คือ 12 Columns นั่นเอง
สังเกตว่าความกว้างของ Container ที่ Breakpoint ส่วนใหญ่จะคงที่ ไม่ได้ยืดหดตามจอ (ยกเว้นเมื่อจอหดลงมาเป็นขนาดเล็กสุด) ดังนั้นเวลาเราออกแบบก็เป็นตามขนาดของ Container ในแต่ละช่วง Breakpoint ได้เลยครับ ทดสอบการยืด/หดกับแค่ Breakpoint ที่เล็กที่สุดก็เพียงพอ ยกเว้นถ้าอยากให้ Container ของเราเต็มจอตลอด แบบนั้นก็จะต้องระวังเรื่องการยืด/หด ของ Container โดยลองยืดหด Design ของเราอย่างที่ได้เล่าเรื่อง Responsive Design ไปในตอนที่แล้ว
ดังนั้นเวลา Designer ออกแบบ UI ควรจะทำ Layout ให้ลงกับระบบ Grid
เพราะการทำ UI ให้ลง Grid จะช่วยให้เราสื่อสาร Design กับ Developer ง่ายขึ้น ช่วย Developer ประหยัดเวลาในการโค้ด แถมยังทำให้งาน UI ของเราเป็นระเบียบเรียบร้อย และรองรับ Responsive ได้ดีขึ้นอีกด้วย
ซึ่ง Designer ที่ทำงานใน Figma สามารถเปิด Layout Grid แบบ Columns ขึ้นมาเพื่อเป็นไกด์ในการออกแบบได้ครับ
Library อื่นๆ
นอกจาก UI Frameworks ต่างๆ แล้ว ในโลกของ Developer ยังมี Library แบบอื่นๆ ให้เลือกใช้ได้อีกมากมาย อย่างเช่น
- ถ้าอยากได้แผนที่มาแสดงบนแอป ก็หยิบ Google Maps API, Mapbox, หรือ OpenStreetMap มาแปะ
- ถ้าอยากได้สไลด์เลื่อนๆ บนหัวเว็บ ก็มี Owl Carousel หรือ Slick ให้เลือกใช้
- ถ้าอยากได้กล่อง Popup สวยๆ ก็มี Library อย่างเช่น SweetAlert
- ถ้าอยากได้กล่อง Select แบบแอดวานซ์ๆ มีกล่องค้นหา กดตัวเลือกหลายอันได้ ก็ใช้ React Select ได้
- ถ้าอยากได้ List ที่ผู้ใช้ลากของไปมาเพื่อเรียงลำดับได้ ก็หยิบ Sortable มาใช้
- หรืออยากวาดกราฟในเว็บ ก็มี Chart.js, Highcharts, หรือ Plotly (JS) มาช่วย
จะเห็นว่าในโลกของ Library นั้นมีคนเขียนโค้ดสำหรับทำ UI ไว้หลากหลายชนิดมากๆ ซึ่งเครื่องมือเหล่านี้จะช่วยให้ Developer ประหยัดเวลาในการโค้ด เพราะไม่ต้องทำ UI พวกนี้ใหม่ตั้งแต่ต้น เพียงแค่นำมาปรับแต่งให้เข้ากับหน้าตาของแอป และไม่ต้องคอยพะวงกับรายละเอียดต่างๆ ของตัว UI Element เอง
ฝั่ง Designer เองสามารถใช้ประโยชน์จากสิ่งนี้ได้เช่นกัน โดยเมื่อเราออกแบบและอยากได้ UI Component แปลกๆ ที่ไม่ใช่มาตรฐาน ก็อาจจะลองถาม Developer ในทีมได้ว่าถ้าเราอยากได้ Component แบบนี้ เขาจะใช้ Library ตัวไหนเพื่อทำสิ่งนี้ (อย่าลืมว่า Developer แต่ละคนจะมีประสบการณ์กับ Library แต่ละชุดแตกต่างกัน) เมื่อได้ข้อมูลจาก Developer แล้วก็มาลองดูว่า Component พวกนั้นทำงานเหมือนที่เราต้องการไหม และสามารถปรับแต่งอะไรได้บ้าง เพียงเท่านี้เราก็จะทำงานกับ Developer ได้ราบรื่นขึ้น ประหยัดเวลาทั้งสองฝ่าย
[สรุป] ได้รู้เรื่อง UI Library/Frameworks แล้ว Designer ควรจะทำอย่างไรให้ทำงานกับ Developer ได้ดีขึ้น?
สำหรับบทความนี้เราก็ได้ลงลึกขึ้นเรื่องการทำงานของ Developer และสิ่งที่ Designer ควรรู้ สรุปได้ดังนี้
- ถือหลัก “DRY” (Don’t Repeat Yourself) อะไรที่นำมาใช้ซ้ำได้ก็ควรใช้ซ้ำ ควรสร้างเป็น Components และจัดระเบียบชุด Component ด้วย Variants และ Properties และรวบรวม Components ไว้เป็น Component Library หรือ Design System
- จัดเก็บค่าสี ค่าตัวเลข ฟอนต์ ที่ใช้บ่อยๆ ไว้เป็น Styles หรือ Design Tokens และใช้ Styles ใน Figma เพื่อจัดระเบียบฟอนต์และสี
- ลองศึกษา Native Components ของแพลตฟอร์มที่เราออกแบบ และดู UI Framework และ Library ต่างๆ ว่ามีอะไรให้ใช้บ้าง ปรับแต่งอะไรได้บ้าง ตรงไหนควรใช้ Native หรือจะออกแบบ Custom Component ใหม่ดี
- ทำ Design ให้ลงกับ Grid System คิดเผื่อการยืดขยายจอให้รองรับ Responsive
และโดยเฉพาะกับเรื่อง Components แบบนี้ ที่มีความแตกต่างกันในแต่ละแพลตฟอร์ม แล้วแต่ทีม แล้วแต่ Developer แต่ละคนว่าจะใช้เครื่องมือชุดไหน ย้ำอีกครั้งว่าสิ่งที่สำคัญที่สุดก็ยังคงเป็นการทำงานกับ Developer อย่างใกล้ชิด เพื่อทำความเข้าใจว่าอะไรทำได้/ไม่ได้ แบบไหนทำง่าย/ยาก เช่นเดิมครับ 🙂
สำหรับตอนต่อไป ก็ไปลุยกันต่อเลยกับฝั่งหลังบ้านกันบ้าง
และสำหรับใครที่ยังไม่ได้อ่านตอนแรกของซีรีส์นี้ ก็กลับไปตามอ่านได้ที่นี่ครับ
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
